Platform/Features/IonMonkey

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

IonMonkey is a new JIT for SpiderMonkey. Our goal is to implement a new compiler to enable many new JavaScript optimizations. In particular IonMonkey will feature much more organized and explicit data structures typical of advanced compilers. This goal of being clean and flexible will be extremely important for future optimization work and experimentation.

2. Users & use cases

Goals:

• Provide a backend that can match or beat the Trace JIT or Crankshaft in speed. Sub-goals:
  • Fine-grained specialization and de-specialization.
  • Integration with type inference.
• Clean, textbook IR so optimization passes can be separated and pipelined with well-known algorithms.
• Document and comment well so the implementation and its side effects can be easily understood.
• Recompilation, debugging, bailouts are all related - and should be solved up-front.
• First SpiderMonkey JIT that starts off with peer reviews!
• (Unknown feasibility) Act as a baseline compiler to replace JM2.
• Manage memory much better, in part to avoid range problems on x64.

Avoiding these:

• Aggressive stores. We should move state syncing to bailout points.

3. Dependencies

`

4. Requirements

• Does not regress correctness.
• Does not regress usability or bench-marketing performance.

Non-goals

`

Stage 2: Design

5. Functional specification

See bug 646923 for an experimental design in Python, and bug 650181 for IR plans.

See /RegisterAllocator for information on the register allocator interfaces.

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

1. Bailouts
   1. What: Bailouts are the heart of the optimizing compiler. When speculation fails (triggering a type, shape, overflow guard, etc), or C++ throws an exception, or needs to GC, we must be able to inspect the JIT frame, and if needed, reconstruct an interpreter frame.
   2. Dependencies:
      1. Register allocator
      2. Code Generator
   3. Work involved:
      1. Implementing guards
      2. Snapshot building at guard points
      3. Bailout trampoline
      4. Frame reconstruction
   4. Priority: Critical, blocks testing
   5. Time: 2-3 weeks
   6. Owner: dvander
   7. Status: DONE
2. Calls out to C++
   1. What: Ability to call into C++ from JIT code.
   2. Dependencies: Bailouts
   3. Work involved:
      1. Macro assembler interface for managing calls.
      2. Ability to recover bailout information from within C++.
      3. C++ function calling convention (bake in JSCompartment, hold active ion cx?)
      4. Protocol for dealing with exceptions returned from C++ functions
      5. GC needs to walk Ion frames
   4. Priority: Very high
   5. Time: 4+ weeks
   6. Owner: npierron
3. Property Access and Inline Caches
   1. What: Code to handle property access sites
   2. Dependencies: Bailouts, Calls out to C++
   3. Work involved:
      1. TypeOracle interface for learning about property accesses.
      2. Four cases of knowledge: Monomorphic, Polymorphic, Megamorphic, and Unknown (IC)
      3. Building JM-like IC structures into IM, solving old memory management problems like reset-on-GC, bloated IC structs
   4. Priority: High
   5. Time: 4-5 weeks?
   6. Owner: TBD
4. Function calls
   1. What: Ability to call other Ion or interpreter JS functions
   2. Dependencies: Bailouts
   3. Work involved:
      1. Handle monomorphic versus polymorphic calls (ICs).
      2. Handle arity mismatches.
      3. Modify trampolines and calling convention so frame reconstruction can restore nested frames.
   4. Priority: High
   5. Time: 4+ weeks
   6. Status: Done, except for TI integration.
   7. Owner: sstangl
5. Baseline Compiler
   1. What: A compiler that replaces JägerMonkey as an untyped and fast compiler.
   2. Dependencies: None, but needs close integration with ICs and type profiling
   3. Work involved: Explore problem space. Ideally, we want to use IonMonkey as the baseline compiler, but whether the compiler itself is fast enough is an open question. Similarly, the expense of taking and translating snapshots must be measured on scripts with a huge number of local variables.
      1. If IonMonkey is fast enough, we can just use it.
      2. If optimization passes are expensive, we can turn them off.
      3. If snapshots are too expensive, we can eliminate them and insert IR nodes to incrementally sync the stack.
      4. If IonMonkey is too slow, we can write a new baseline compiler and possibly consider it generating off MIR.
      5. Further work stems from this decision.
   4. Priority: High
   5. Time: 4 months
   6. Owner: TBD
6. Type Feedback
   1. What: Feedback mechanism to inform IonMonkey about likely types of access sites.
   2. Dependencies: ICs
   3. Work involved:
      1. Explore problem space. Ideally we want to learn about types from ICs, using either previous IonMonkey runs or information from the baseline compiler (Ion or not). Therefore we should aim to share IC structures between all compilers.
      2. Implement a TypeOracle derivation that uses run-time profiling to inform IonMonkey.
   4. Priority: High
   5. Time: 4 weeks
   6. Owner: TBD
7. Type Inference Integration
   1. What: Integrate IonMonkey's type system to Brian Hackett's type inference engine.
   2. Dependencies: None
   3. Work involved:
      1. Use Type Inference to determine specializations and inlining.
      2. Make a TypeOracle that uses inference results to inform IonMonkey.
      3. Support on-stack invalidation.
   4. Priority: High
   5. Time: 4 weeks
   6. Owner: dvander
8. Method Inlining
   1. What: Inline methods
   2. Dependencies: Bailouts, either profiling, ICs, or calls out to C++
   3. Work involved:
      1. Some heuristic to determine whether methods should be inlined (this can be totally bogus, but maybe better to start with simple methods).
      2. Changing IonBuilder such that JSScripts bytecode parsing can be "stacked" so inner SSA graph is inlined.
      3. Change M/LSnapshots to be nested, so snapshots in an inner frame all point to the same outer snapshot.
      4. Change snapshot encoding and frame reconstruction to support inlining.
   4. Priority: Medium
   5. Time: 3 weeks
   6. Owner: cdleary
9. On-Stack Replacement
   1. What: Jump into JIT code at loop headers, possibly by profiling off-thread.
   2. Work involved:
      1. Explore ways to monitor hotness of JIT code.
      2. Implement the ability to jump into Ion-compiled code at loop headers, possibly by inserting special OSR nodes in the IR.
   3. Priority: Medium
   4. Time: 4 weeks
   5. Owner: sstangl
10. ARM Port
    1. What: Port IonMonkey to ARM
    2. Work involved:
       1. Bootstrap ARM to x86 parity so both develop at the same time.
    3. Priority: High
    4. Time: 4 weeks
    5. Owner: mrosenberg
11. Debugging
    1. What: Work with jsd/jsdbg2 or whatever debugging APIs are required.
    2. Dependencies: Bailouts, Baseline JIT
    3. Work involved:
       1. Deoptimizing from within C++
       2. Calling debug hooks/probes
       3. Implementing breakpoints, EvalInFrame
    4. Priority: Low (for now)
    5. Time: ???
    6. Owner: TBD
12. Testing
    1. What: We should be testing everything - correctness, perf, memory.
    2. Dependencies: Bailouts
    3. Work involved:
       1. Making sure tbpl stays green, frequent merging from m-c.
       2. Breaking down memory, cpu time of each Ion pass.
       3. AWFY lines.
    4. Priority: High
    5. Time: Continuous
    6. Owner: everyone

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes